feat: Implement tracing & thiserror error types
#29
Conversation
|
@zeeshanlakhani Tagged you as a reviewer on this PR, specifically for the tracing commit ( 436c1b6 ), since you're more knowledgeable on tracing. LMK what you think ✌️ |
|
Clippy warning is triggered within the A little annoying. I'll try ignoring the warning until that issue is closed. |
| } | ||
|
|
||
| match dag_verification.block_state(cid) { | ||
| BlockState::Have => continue, | ||
| BlockState::Unexpected => { | ||
| eprintln!("Warn: Received block {cid} out of order, may be due to bloom false positive."); | ||
| trace!( |
There was a problem hiding this comment.
trace! is the lowest level. Should this be a warn?
There was a problem hiding this comment.
It's trace intentionally.
I used to think of this as a warning - it's one of the things that if something goes wrong, this may happen more often.
But it's also something that just happens during normal execution, so more like some info.
There was a problem hiding this comment.
ah ok. yeah, from the comment it made it sound worse than it is :).
This implements tracing messages using the
tracingcrate and error types using thethiserrorcrate.Closes #25
Closes #26
I'm somewhat waiting for n0-computer/iroh-car#12 to land so I can improve the error types a bit.
Additionally, it'd be nice to have a better
BlockStoretrait eventually, so (1) we can get rid off theBlockStoreIncompatibleerror and (2) use a custom error type from theBlockStoreinstead of a hard-codedanyhow::Error.